如果你曾經開始學 Kubernetes，很可能經歷過這樣的流程：

看影片理解 Pod、Deployment、Service，好像都聽懂了。

接著開始照著教學輸入：

kubectl apply -f deployment.yaml
kubectl get pods
kubectl get svc

畫面成功跑出 Running，覺得自己好像會 Kubernetes 了。

隔兩天有人問：

「Deployment、ReplicaSet 和 Pod 到底是什麼關係？」

腦袋突然一片空白。

或者遇到：

CrashLoopBackOff

第一反應不是分析，而是把錯誤訊息複製貼給 ChatGPT。

我自己認為 Kubernetes 難學的原因，不完全是它複雜，而是很多教材的學習方式容易變成：

今天 Pod
明天 Deployment
後天 Service
再來 ConfigMap

每一個名詞都懂一點，但不知道它們為什麼要一起存在。

所以這 30 天，我想換一種方式。

我們不會建立 30 個彼此無關的小範例。

我們會從 Day 1 開始，共同養出同一套 Kubernetes 系統。

這 30 天最後要完成什麼？

我們會從一個非常簡單的 FastAPI 開始，最後逐漸變成：

                    Client
                       │
                       ▼
                    Gateway
                       │
                       ▼
                   HTTPRoute
                       │
                       ▼
                    Service
                       │
                 ┌─────┴─────┐
                 ▼           ▼
              API Pod      API Pod
                 │
          ┌──────┴──────┐
          ▼             ▼
       Service        Service
        Redis        PostgreSQL
          │             │
          ▼             ▼
       Redis Pod     PostgreSQL Pod
                         │
                         ▼
                        PVC
                         │
                         ▼
                         PV

後面還會逐漸加入：

ConfigMap
Secret
Readiness Probe
Liveness Probe
HPA
NetworkPolicy
RBAC
Gateway API
Scheduling
DaemonSet
Job / CronJob
Helm
Kustomize
etcd
GitHub Actions
GitOps

但是我們不會第一天全部裝完。

因為真正學 Kubernetes 最容易踩的坑就是：

還不知道 Service 是什麼，就開始裝 Helm、Ingress、Argo CD、Prometheus。

最後出問題時，完全不知道是哪一層壞掉。

所以這個系列的原則是：

一次只增加一個複雜度。

為什麼不直接用 AWS EKS、GKE 或 AKS？

因為我們現在的目標是：

學 Kubernetes。

而不是：

同時學 Kubernetes + VPC + IAM + Security Group + Load Balancer + Cloud Billing。

我們前半段全部使用自己的電腦。

環境會是：

Mac / Windows / Linux
        │
        ▼
      Docker
        │
        ▼
       kind
        │
        ▼
   Kubernetes Cluster

kind 的全名是：

Kubernetes IN Docker

它會把 Kubernetes Node 跑在 Container 裡。

所以你不用租三台 Server，也能建立：

control-plane
worker
worker

的 Kubernetes Cluster。

更重要的是：

玩壞完全沒關係。

最慘就是：

kind delete cluster

重新建立。

對學習來說，這反而比 Production Cluster 更適合。

Kubernetes 到底是拿來幹嘛的？

先不要背官方定義。

假設今天我們有一個 API：

FastAPI

最開始只有一個 Container：

API Container

流量增加後，我們開三個：

API Container
API Container
API Container

這時問題開始出現。

其中一個 Container 掛掉：

誰負責重新啟動？

流量突然增加：

誰負責多開幾份？

新版 API 要上線：

怎麼避免三個 Container 一次全部停止？

IP 改掉：

其他服務要怎麼找到它？

某台 Server 掛掉：

Container 要搬去哪裡？

這些事情如果全部由工程師手動處理，系統規模一大，很快就會失控。

Kubernetes 真正要解決的，就是這些事情。

因此我很喜歡用一句話理解 Kubernetes：

你告訴 Kubernetes「我希望系統長什麼樣子」，Kubernetes 持續把現實世界修正成你希望的樣子。

例如：

Desired State
API Pod = 3

但是現在：

Actual State
API Pod = 2

Kubernetes 發現：

2 ≠ 3

於是幫你補回一個。

這個概念叫做：

Reconciliation

也是接下來 30 天會一直看到的核心思想。

這系列不只追求「會部署」

我希望最後你看到：

Pending

會自然想到：

Scheduling？
Resource 不夠？
PVC？
nodeSelector？
Taint？

看到：

ImagePullBackOff

會想到：

Image 名稱？
Tag？
Registry？
Pull Policy？

看到：

Running 0/1

會想到：

Readiness Probe？

看到：

Pod 明明 Running，但 Service 打不到

會想到：

Selector？
EndpointSlice？
Port？
NetworkPolicy？

這才是真正「會 Kubernetes」。

30 天的學習方式

每天文章都會維持同一個節奏。

先回答：

今天到底遇到什麼問題？

再介紹：

Kubernetes 用什麼機制解決？

接著：

真的動手做。

最後再：

故意把它弄壞。

因為一個 Kubernetes 功能，如果你只看過它正常工作的樣子，其實只學了一半。

知道它壞掉長什麼樣子，才真正開始懂它。

Day 1 小結

今天還沒有輸入任何 Kubernetes 指令。

但這反而是整個系列最重要的一篇。

先記住三件事情。

Kubernetes 不是 Docker 的替代品。

Docker 解決：

怎麼把 Application 包成 Container？

Kubernetes 解決：

大量 Container 怎麼被部署、找到、更新、擴展與維持正常？

第二，Kubernetes 最核心的思想不是 kubectl。

而是：

Desired State
↓
Controller
↓
Actual State

第三，接下來我們不是讀 30 篇獨立筆記。

我們會真的架構出：

一套屬於自己的 Kubernetes 系統。

明天我們先暫時不碰 Kubernetes。

因為要真正理解 Kubernetes，第一件事情反而是：

為什麼只有 Docker 還不夠？